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1.0  SUMMARY 


This  report  documents  the  results  of  experiments  performed  to  demonstrate  use  of 
commercial-off-the-shelf  (COTS)  wireless  networking  technology  as  a  surrogate  for  military- 
grade  networking  equipment  in  the  investigation  of  Joint  Aerial  Layer  Network  (JALN)  concepts. 
Field  measurements  were  performed  at  the  Air  Force  Research  Laboratory's  (AFRL's)  Newport 
Test  Facility  using  a  scaled-down  JALN  architecture. 

A  number  of  static  ground  nodes  were  linked  using  a  variety  of  COTS  wireless  bridges 
and  access  points  which  provided  communication  channels  at  of  different  frequency  and 
capacity.  In  addition,  a  Mini-Common  Data  Link  (Mini-CDL)  radio  was  utilized  for  making  side- 
by-side  performance  comparisons  of  COTS  and  military  wireless  technology.  Measurements 
were  made  to  a  assess  link  capacity  by  incrementally  increasing  channel  utilization.  Varying 
amounts  of  text,  voice  and  video  data  were  transferred  between  network  nodes  and  the  data 
rates  were  recorded.  Results  are  presented  and  the  implications  for  testing  network  operations 
are  discussed. 

This  experiment  has  successfully  demonstrated  that  COTS  wireless  technology  can  be 
used  to  examine  design  issues  that  will  challenge  JALN  developers.  The  use  of  low-cost  COTS 
wireless  technology  is  found  to  be  a  suitable  surrogate  for  military  hardware  for  investigating 
networking  problems  expected  to  be  encountered  in  an  aerial  Layered  network  (ALN). 
Additional  field  experiments  are  being  planned  that  will  involve  a  larger  number  of  nodes  and 
links.  The  work  will  also  employ  dynamic  routing  to  further  challenge  network  operations  and 
better  represent  JALN  operations. 
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2.0  INTRODUCTION 


The  objective  of  this  in-house  effort  is  to  research,  develop  and  evaluate  a  wireless  topology  for 
addressing  the  network  connectivity,  capacity,  data  sharing,  and  management  issues  associated 
with  next-generation  military  communications  networks,  such  as  the  Department  of  Defense's 
Joint  Aerial  Layer  Network  (JALN).  A  general  lack  of  synergy  between  military  operators, 
government  labs,  industry,  and  the  academic  community  in  resolving  increasingly  complex 
problems  of  integrating  and  operating  wireless  technologies  presents  obstacles  to  the  adoption 
of  new  networking  approaches.  This  effort  proposes  to  make  use  commercial-off-the-shelf 
(COTS)  wireless  technologies  as  cost-effective  data  link  surrogates  for  instantiating  a  JALN  test 
bed  concept. 

Mobile  nodes  will  be  assembled  using  different  combinations  of  these  devices  to  create 
network  conditions  encountered  in  JALN-like  scenarios.  Link  conditions  will  be  measured  and 
networking  concepts  will  be  evaluated  to  assess  the  effects  on  application  services,  such  as 
streaming  video  and  voice,  chat,  data  file  transfers  and  database  queries  executed  over  the 
network.  Routing  technologies  and  topology  control  mechanisms  will  be  studied  in  an  effort  to 
quantify  the  impacts  on  throughput,  latency,  and  scalability  as  network  topologies  change  in  an 
ad  hoc  environment.  The  cost-effective  approach  provides  a  convenient  framework  for 
identifying  and  investigating  key  design  drivers  that  impact  development  of  current  and  future 
JALN  concepts. 

The  typical  Operational  View  (OV)  chart,  such  as  that  illustrated  in  Figure  1,  usually 
illustrates  battlefield  connectivity  using  "lightning  bolts"  or  "line  segments"— implying  that 
network  connectivity  is  a  trivial  undertaking.  The  truth  is,  implementing  reliable  and  secure 


Figure  1  -  Nominal  Joint  Aerial  Layer  Network  Diagram. 
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tactical  network  communications  is  difficult;  in  that  modern  tactical  operations  can  involve 
large  numbers  of  operational  personnel  and  equipment  that  are  deployed  in  complex  combat 
situations.  As  one  system  designer  explains  it:  "Every  customer  we  talk  to  recognizes  that  the 
network  is  hybrid. ..One  technology  doesn't  solve  all  problems.  Satellites  can't  solve  100  percent 
of  the  communication  requirements;  tactical  radios  can't;  Wi-Fi  can't.  It  is  a  combination  of  all 
these  technologies  in  an  architecture  that  ultimately  makes  sense  to  deliver  the  capability  to 
the  warfighter  [2]."  And  given  the  rapid  rate  of  change  in  wireless  technologies,  communication 
system  designers  need  to  be  continually  re-thinking  and  re-evaluating  just  what  makes  sense 
with  regards  to  information  delivery.  An  effective  aerial  layer  network  not  only  incorporates 
newly  available  technological  advances  as  needed,  but  also  is  able  to  seamlessly  integrate  with 
existing  systems  and  networks  [3].  And  many  changes  in  the  military  operating  environment  are 
now  being  driven  from  the  bottom-up,  by  younger  users  familiar  with  instant  messaging,  web 
services  and  multi-media  in  their  non-military  lives. 

The  USAF  Airborne  Network  Special  Interest  Group  [4]  identifies  the  key  defining 
architectural  elements,  components,  and  design  objectives  for  future  Aerial  Networks  (ANs)  in 
terms  of  the  connectivity  that  can  be  established,  the  services  that  can  be  supported  over  the 
network  connections,  and  the  operations  that  are  required  for  the  user  to  establish,  maintain 
and  access  the  network  connections. 

•  Connectivity  includes:  coverage,  diversity  of  links,  throughput,  type  of  connection,  and  network 
interface  (e.g.,  geographic  span  of  links,  total  number  and  type  of  links,  and  nature  of  connections 
that  can  be  established). 

•  Services  include:  real-time  data;  continuous  interactive  voice  (e.g.,  voice  over  IP  telephone  and 
radio  nets);  continuous  interactive  video  (e.g.,  video  over  IP,  video  teleconferencing);  streaming 
multimedia  and  multicast  (e.g.,  video  imagery);  block  transfer  and  transactional  data  (e.g.,  Telnet, 
HTTP,  client/server,  chat);  and  batch  transfer  data  (e.g.,  email,  FTP). 

•  Operations  include:  managing  the  links  and  network;  planning  (e.g.,  frequency  allocation, 
transmission,  routing,  and  traffic);  monitoring  (e.g.,  performance  and  use,  fault,  and  security); 
analyzing  (e.g.,  performance  optimization,  diagnostics);  controlling  (e.g.,  add,  remove,  initialize, 
and  configure  links,  networks,  or  network  components);  forming  and  adapting  (e.g.,  provisioning 
and  obtaining  need  link  and  network  resources,  and  initialization  and  restoration  of  a  link  or 
network  service);  and  protection  (i.e.,  communications  security  as  well  as  authentication, 
authorization,  accounting  detection,  and  reaction). 

It  is  expected  that  next  generation  ALNs  will  be  capable  of  connecting  all  platforms, 
supporting  all  needed  information  services,  and  guaranteeing  certain  levels  of  performance  to 
support  bandwidth,  latency  or  loss-sensitive  applications.  The  demands  placed  on  future 
tactical  communications  systems  will  only  intensify  as  users'  information  needs  and  delivery 
options  increase.  As  such,  the  development,  adoption  and  deployment  of  new  communications 
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technologies  is  critical  to  the  timely  sharing  of  situational  awareness  data  between  sensors, 
decision-makers  and  weapon  systems  regardless  of  their  location  [5]. 

The  Air  Force's  2012  Aerial  Layer  Networking  Enabling  Concept  document  defines  an  ALN 
"as  the  integration  and  application  of  processes,  procedures,  and  policies  that  provide  the 
framework  for  sharing,  exchanging,  and  using  data  that  originates,  traverses,  or  terminates  on 
any  AF  platform  in  a  joint  operational  area"[6].  The  document  goes  on  to  state  that: 

•  Future  ALN  systems  must  be  modular  and  use  open  standards  to  allow  AF  platforms  to 
adapt  quickly  to  new  mission  needs  and  technology  improvements. 

•  Networks  are  required  to  provide  connectivity  across  the  multiple  disparate  physical 
waveforms  which  will  be  used  throughout  the  aerial  layer.  Several  different  network 
domains  will  need  to  be  operated  within  the  aerial  layer  to  meet  the  various  information 
assurance  requirements ,  policies  and  functional  system  requirements  which  exist 
throughout  the  warfighting  environment. 

•  An  information  sharing  infrastructure  must  be  established  and  managed  to  achieve  end-to- 
end  interoperability.  The  information  sharing  infrastructure  will  leverage  the  rapid 
advancement  of  technology  and  economy  of  scale  in  the  commercial  sector  to  enable  on- 
demand,  real-time  and  secure  exchange  of  voice,  data,  video,  control  and  management 
information  across  the  ALN  and  its  external  interfaces. 

•  Scalability  is  important  as  transformation  from  tactical  data  links  to  network  architecture 
will  take  place  incrementally  over  the  years. 

•  The  infrastructure  will  be  designed  to  leverage  user  experience  to  ensure  that  effective 
capabilities  are  provided  to  the  warfighter,  especially  over  mobile,  low  bandwidth  and 
unstable  networks. 

Implementing  next  generation  of  ALNs,  using  legacy  systems  and  existing  networking 
architectures,  have  not  yielded  needed  levels  of  effectiveness.  Meeting  the  wide  range  of 
operational  requirements  deemed  critical  to  future  Air  Force  missions,  will  most  likely  require 
use  of  an  equally  wide  range  of  networking  approaches.  New  technologies  and  networking 
approaches  being  developed  for  commercial  applications  cannot  be  excluded  from 
consideration. 
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3.0  METHODS,  ASSUMPTIONS,  AND  PROCEDURES 


The  objective  of  this  effort  was  to  implement  a  low-cost  wireless  network  for  the  purpose  of 
demonstrating  that  commercially  available  devices  and  applications  can  be  employed,  as  low- 
cost  surrogates  for  military-grade  hardware,  in  the  investigation  and  evaluation  of  various 
networking  concepts  to  help  further  development  of  aerial  layer  networks. 

Three  core  principles  were  preserved  throughout  development  of  the  network  used  in 
the  experiment  to  represent  a  surrogate  JALN.  The  first  was  minimizing  the  cost  of  hardware. 
The  price  of  each  device  was  not  to  exceed  $500.00.  The  second  was  to  avoid  proprietary 
device  functionality.  This  included  choosing  protocols  and  applications  that  were  standards 
across  industry,  rather  than  a  function  only  specific  to  a  certain  manufacture.  Finally,  the  third 
was  to  ensure  repeatability. 

The  location  chosen  to  implement  this  surrogate  network  was  AFRL's  Newport  Test 
Facility.  The  facility  offered  a  quiet  RF  environment  and  provided  distances  between  links  that 
could  be  scaled  (100:1)  appropriately  to  theater.  An  aerial  view  of  the  Test  Facility's  two  hilltop 
sites  (Tanner  Hill  and  Irish  Hill)  is  provided  in  Figure  2. 


Figure  2  -  Newport  Test  Facility  Aerial  View. 
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3.1  Network  Design 

The  experiment's  network  topology  is  representative  of  the  high  capacity  communication  links 
(10  Mbps-274  Mbps)  employed  between  high  and  medium  altitude  airborne  nodes -such  as 
those  links  highlighted  in  the  JALN  OV  diagram  shown  in  Figure  3.  Here  line  segments  signify 
communication  link  availability,  while  colors  (yellow,  red,  blue,  and  black)  indicate  link  of  similar 
bandwidth.  This  topology  was  in  turn  scaled,  in  terms  of  range,  in  order  to  allow  for  its  set-up 
at  AFRL's  Newport  outdoor  test  ranges. 


Figure  3  -  Experiment  Architecture  Overlaid  on  JALN  Concept  Diagram. 


The  IEEE  wireless  (WiFi)  standard  802.11g/n  was  used  with  COTS  devices  to  provide  a 
cost  effective  data-link  surrogate.  These  devices  provided  representative  high  capacity  links 
with  a  bi-directional  rate  ranging  from  10-30  Mbps.  Additional  data-links  were  also  established 
to  emulate  backup  data-links.  Different  wireless  frequencies  were  dedicated  to  these  links.  All 
primary  links  operated  over  the  5  GHz  frequency  range,  while  backup  links  operated  over  the 
900  MHz  and  2.4  GHz  ranges.  To  offer  a  comparison  between  the  COTS  devices  and  a  tactical 
high  capacity  tactical  link,  a  mini-CDL  operating  over  the  KU  band  was  also  incorporated  into 
the  design.  Figure  4  shows  the  JALN  diagram  transposed  to  different  sites  within  the  Newport 
facility.  The  figure  also  identifies  the  backup  links  and  their  associated  frequency.  The 
geographical  location  of  the  wireless  links  at  the  Newport  facility  can  be  seen  in  Figure  5. 
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Figure  4  -  Joint  Aerial  Layer  Network  Diagram  (Newport  Transposed). 


Figure  5  -  Newport  Facility  Wireless  Links. 
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The  network  was  designed  so  that  each  site  would  have  a  router,  switch,  wireless  access 
point,  and  a  wired  workstation  along  with  various  wireless  devices  such  as  laptops,  tablets  and 
cameras  all  contained  within  a  local  network.  Connections  between  the  routers  were  made 
using  one  or  more  wireless  access  points  that  operated  in  AP/Client  mode  (similar  to  bridge 
mode).  The  wireless  access  points  were  high  power  and  contained  directional  antennas 
offering  the  necessary  range  across  the  hills. 

Each  of  the  local  networks  consisted  of  a  class  B  IPv4  network  address,  with  a  16-bit 
subnet  mask,  allowing  up  to  65,534  nodes.  The  wireless  links  between  each  site  were  also 
contained  within  a  local  subnet  and  used  class  C  IPv4  network  addresses  with  a  24-bit  subnet 
mask.  Class  C  addresses  were  chosen  since  the  number  of  nodes  would  be  limited  to  those 
needed  to  create  a  secure  wireless  connection,  much  less  than  the  number  of  nodes  at  each 
site.  Figure  6  shows  the  network  topology  and  IP  address  structure  of  the  JALN  surrogate. 


JALN  Surrogate  Design 


Tanner  Hill  Site  A 
Ops  Building 

High  Alt  Airborne  CC 
1  Wired  Laptop 

Tanner  Hill  Site  E  Short  2  Wireless  Laptops 
Range  Tower 

Ground  CC 

1  Wired  Laptop 

2  Wireless  Laptops 


Irish  Hill  Site  B 
Iso-Range  S-280 

Ground  Node 

1  Wired  Laptop 

2  Wireless  Laptops) 

Irish  Hill  Site  D 
Guard  Shack 

Airborne  Node 

1  Wired  Laptop 

2  Wireless  Laptops) 


172.40.0.2 
SSID:  TH-E 
THEWAPOl 
2.4  WAP 
Chan  l 


Rev:  3.0 
Date:  260ct  12 


*x.x  IP  Address  denote  192.168.x.x 


900  MHz 
CDL 


Figure  6  -  JALN  Surrogate  Network  Design. 
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Different  routing  methods  i.e.,  dynamic  versus  static  were  researched  and  evaluated  in 
the  lab.  And  while  a  dynamic  routing  protocol  would  in  all  likelihood  provide  the  versatility 
needed  for  testing  purposes,  static  routing  was  instead  used  to  ensure  repeatability  and  control 
of  network  response.  Static  routes  proved  to  be  the  most  reliable  and  allowed  for  the  focus  to 
be  placed  on  the  wireless  connectivity  rather  than  on  routing  operations.  The  use  of  static 
routing  also  provided  a  means  for  establishing  a  baseline  for  how  link  failover  should  operate  in 
a  tactical  environment.  Static  routes  were  set  up  manually.  Whenever  redundant  links  were 
used  between  sites  metrics  were  employed  to  determine  link  priority.  All  primary  routes  were 
given  the  highest  metrics  while  the  backup  routes  were  assigned  lower  ones. 

Frequency  management  was  also  of  concern.  In  order  to  maximize  link  bandwidth, 
wireless  access  points,  including  each  site's  local  access  point  and  the  site-to-site  directional 
access  points  needed  to  have  the  correct  channel  separation  and  physical  placement  and 
alignment.  This  would  ensure  proper  access  point  isolation  and  would  maximize  the  channel 
bandwidth  across  the  wireless  link.  Figure  6  above  shows  the  channel  configuration  for  each 
wireless  access  point. 

3.2  Hardware  Configuration 

Prior  to  conducting  the  field  experiment,  each  of  the  network  devices  were  researched  and 
their  performance  evaluated  against  available  alternatives.  The  routers  selected  were  MikroTik 
450g™  amd  MikroTik  493g™  models  both  running  MikroTik  RouterOS™.  These  units  offered  a 
number  of  features  set  by  industry  standards  at  minimal  costs.  Other  small-business  routers, 
such  as  a  Cisco  RV016™  and  a  Netgear  SRX5308-100NAS™,  were  evaluated  but  were  found  to 
have  limited  configuration  options  for  static  routing  and  their  use  was  constrained  by  the 
number  of  proprietary  functions.  Site  A  used  a  9-port  MikroTik  493g™  while  Sites  B,  D,  and  E 
each  used  a  5-port  MikroTik  450g™.  Each  site  also  contained  a  layer-2  Netgear  GS108NA™ 
switch.  Each  router  was  configured  with  a  local  LAN  port  and  a  number  of  WAN  ports  for 
wireless  connections  to  adjacent  routers.  Ports  on  both  the  routers  and  the  switches  featured 
full-duplex  and  provided  gigabyte  speeds. 

Each  was  configured  with  WPAv2-AES  encryption  and  was  given  its  own  SSID.  Wireless 
connections  between  sites  were  created  using  TP-Link  TL-WA5210G™,  TP-Link  TL-WA7510N™, 
Ubiquiti  LOCOM900™  and  Mini-CDL  using  the  2.4  GHz,  5  GHz,  900  MHz,  and  KU  band 
frequencies  respectfully.  The  TP-Link™  and  Ubiquiti™  access  points  were  configured  in  pairs 
with  one  in  AP  mode  and  the  other  in  Client  mode.  This  paired-mode  is  similar  to  Bridge  mode, 
but  allows  for  additional  devices  to  connect  directly  to  the  access  point  in  AP  mode.  More 
importantly,  bridge-mode  does  not  allow  for  WPAv2  encryption.  So  while  no  other  additional 
devices  were  connected  to  the  AP  Mode  access  point,  the  units  were  able  to  employ 
encryption.  For  local  site  wireless  access,  Site  A  used  a  TP-Link  TL-WA5210G™  with  a  directional 
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antenna  while  Sites  B,  D,  E  used  a  TP-Link  TL-WA90 ID™  with  omni-directional  antennas.  These 
were  configured  in  access  point  (AP)  mode  and  used  the  2.4  GHz  spectrum.  Each  site  also 
contained  nodes,  consisting  of  one  wired  laptop,  two  wireless  laptops  and  various  cameras  and 
tablets.  Table  1  lists  the  hardware  installed  at  each  site. 


Table  1  -  Site  Hardware  List. 


Site  A 

Site  B 

Site  D 

Site  E 

Ms  me 

Manufacturer 

PM 

Marne 

Manufacturer 

PM 

Mame 

Manufacturer 

PM 

Marne 

Manufacturer 

PM 

TMALTP01 

Lenovo 

1KL50000415 

IHBLTP01 

Lenovo 

1  KL50000415 

IHDLTP01 

Lenovo 

1KL50000415 

THELTP01 

Lenovo 

1KL50000415 

THARTR01 

Miscft  3Jk 

RB493 

IHBRTR01 

MifcK  M. 

RB450G 

IHDRTR01 

RB450G 

THERTR0  1 

Idtes  Ife 

RB450G 

TMAWAP0 1 

TP-Link 

TL-WA5210G 

IHBWAP01 

TP-Link 

TL-WA9Q 1  D 

imWAPOl 

TP-Link 

TL-WA901D 

THEWAP01 

TP-Link 

TL-WA521QG 

THA2  B  R0  1 

TP-Link 

TL-WA5210G 

IHB2BR01 

TP-Link 

TL-WA52 1 QG 

IHD5BR01 

TP-Link 

TL-WA7510M 

THE5BR0  1 

TP-Link 

TL-WA7510M 

THASBIROi 

TP-Lank 

TL-WA7510M 

IHB5BRB1 

TP-Link 

TL-WA7510N 

IMD5BRQ2 

TP-Link 

TL-WA7510M 

THELTPQ2 

DELL 

585Q0Q3TR1 

TMA5BR02 

TP-Link 

TL-WA7510N 

IHB5BR02 

TP-Link 

TL-WA7510M 

IHD9BR01 

LOCOM9Q0 

THELTPQ3 

DELL 

5B60003TR1 

TMA9BRQ1 

LOOOM90D 

IMBLTP02 

Dell 

seeooosTRi 

IHDCDL01 

CDL 

CDL 

THETAB01 

Ssimsjung 

5S60003TM5 

THACDL01 

CDL 

CDL 

IHBLTP03 

Del 

5&G0003TR1 

IHDLTP02 

Dell 

5B60003TR1 

THECAM01 

FOSCAM 

FB910W 

THA5  B  RQ3 

TP-Link 

TL-WA7510N 

IHBCAM01 

FOSCAM 

FB910W 

IHDLTPQ3 

Dell 

5B60003TR1 

THECAMD2 

KUolf 

DCS-942L 

THALTP02 

Dell 

seeooosTRi 

IHBCAMQ2 

OUloJs 

DCS -942  L 

IHDTABQ1 

ASUS 

5B600O3TM6 

THEGAMD3 

FOSCAM 

FIB91QW 

THALTP03 

Dell 

seeooosTRi 

IHBSWT01 

NETGEAR 

GS10SMA 

IHDSWT01 

METGEAR 

GS10BMA 

THECAMQ4 

LX2 

THACAMQ1 

FOSCAM 

FE910W 

IHDCAMD1 

FOSCAM 

FIE910W 

THECAMQ5 

CM042T 

THAGAM02 

DC5-942L 

IHDGAMD2 

GUufc 

DCS-942L 

THESWTQ1 

METGEAR 

GS108MA 

THASWT01 

METGEAR 

GSIOBMA 

IHDGAM03 

Aatak 

CMB42T 

IHDCAMG4 

Uases 

LX  2 

The  photographs  provided  in  Figures  7  through  11  show  the  antenna  installations  at 
each  of  the  four  sites.  Included  in  some  of  these  images  are  photographs  of  some  of  the  wire 
cameras  used  at  the  various  locations. 


Figure  7  -  Site  A  Antennas  For  Sites  B  and  D. 
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Figure  8  -  Site  A  Antennas  For  Site  E  and  Local  Access. 


Figure  9  -  Site  B  Antennas  for  Sites  A  and  D. 
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Figure  10  -  Site  D  Antennas  For  Site  A  and  B. 


Figure  11  -  Site  E  Antennas  For  Site  A  and  Local  Access. 
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3.3  Baseline  Data  Rates 


The  wireless  data  links  used  in  this  experiment  utilized  Ubiquity  LOCOM900™  900  MHz  stations, 
TP-Link  TL-WA5210G™  2.4  GHz  stations,  TP-Link  TL-WA7510N™  5  GHz  stations  and  the  military 
grade  mini  CDL  KU  band  transceiver.  It  is  important  to  note  wireless  manufactures  commonly 
advertise  the  max  transmission  rate  (throughput)  based  on  the  IEEE  industry  standards,  see 
Table  2.  The  advertised  and  measured  throughputs  for  the  devices  are  provided  in  Table  3. 


Table  2  -  802.11  Standard  Throughput. 


Standard 

Frequency 

Channel 

Bandwidth 

Max 

Advertised 

Throughput 

802.11b 

2.4  GHz 

20  MHz 

1 1  Mbps 

802.11a 

5  GHz 

20  MHz 

54  Mbps 

802.1  lg 

2.4  GHz 

20  MHz 

54  Mbps 

802.1  In 

2.4/5  GHz 

20/40  MHz 

54-600  Mbps 

Table  3  -  Advertised  and  Measured  Throughput. 


Link 

Freq 

BW 

ADV.* 

RAW* 

EFF.* 

A-B 

2.4  GHz 

20  MHz 

54 

14.5 

14.5 

A-B 

5  GHz 

40  MHz 

150 

27.29 

27.29 

A-D 

5  GHz 

40  MHz 

150 

29.72 

20.8 

A-D 

900  GHz 

20  MHz 

150 

19.99 

12.4 

A-D 

KU- 

Band 

Proprietary 

44.73 

34.07 

34.07 

A-E 

5  GHz 

40  MHz 

150 

34.07 

34.07 

B-D 

5  GHz 

40  MHz 

150 

33 

32.94 

*Unlabeled  rates  in  Mbps 


When  comparing  the  measured  and  advertised  throughput  data  it  becomes  evident  that 
the  advertised  values  are  significantly  higher  than  those  measured.  Aspects  such  as  channel 
bandwidth,  TCP/IP  overhead,  antenna  alignment,  physical  obstructions,  and  channel 
interference  have  major  impacts  on  baseline  data  transmission  measurements.  Antenna 
alignment  and  line  of  sight  have  been  adequately  demonstrated  in  this  experiment  by  manual 
alignment  and  verification  through  each  devices  utility.  The  increase  in  performance  on  the  5 
GHz  link  is  due  to  the  increase  in  channel  bandwidth  from  20  MHz  (in  the  2.4  GHz  link)  to  40 
MHz.  Increasing  the  channel  bandwidth  from  20  MHz  to  40  MHz  theoretically  doubles 
throughput.  However,  an  increase  in  bandwidth  causes  data  transmission  to  be  more 
susceptible  to  noise.  This  noise/interference  will  inevitably  lead  to  packet  retransmissions  thus 
decreasing  effective  throughput  even  further. 
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3.4  Spectrum  Utilization 

Each  wireless  access  point  operates  on  a  designated  channel.  The  900  MHz  device  uses 
a  902-928  MHz  band.  The  channels  available  for  the  2.4  GHz  Bridges,  20  MHz  +  1  on  each  end 
makes  a  total  of  14  22  MHz  channels,  are  shown  in  Figure  12.  The  2.4  GHz  frequency  band  is 
however  the  most  commonly  used  and  it  exhibits  the  most  interference  -  primarily  because  of 
channel  overlap.  Due  to  the  2.4  GHz  band  channel  availability,  the  band  only  allows  for  a 
maximum  of  three  channels  (1,  6, 11  -  14  is  not  to  be  used  and  12  and  13  can  only  be  used 
under  low  power  conditions  in  North  America)  for  fully  independent,  non-overlapping, 
frequencies  at  a  single  location.  Channel  selection  in  the  2.4  GHz  band  needs  to  be  carefully 
considered  to  ensure  channel  availability.  The  5  GHz  frequency  band  is  shown  in  13. 


Channels 

Q]  2  3  4  5  H  7  8  9  10  n  12  13  14 


M 

36  40  44  48  52  56  60  64  149153157161 


5  GHz  lower  and  missile  UNII  bands  O  5  GHz  upper  UNII  bond 


United  States  and  other  countries 
have  approved  11  more  channels. 


100  104 108 116 120 112 124  128 132  136 140 

mmmx 


Figure  13-5  GHz  Channels. 

The  flexibility  of  the  5  GHz  and  relatively  low  use,  compared  to  2.4  GHz,  makes  selecting 
channels  less  of  a  burden.  However,  it  is  possible  to  have  channel  overlap  especially  when  40 
MHz  channel  bandwidth  is  chosen.  The  frequency  for  the  Miniature  CDL  is  KU-Band  and  is 
relatively  free  of  interference  due  to  its  military  frequency  range.  The  theoretical  frequency 
spectrum  for  900  MHz,  2.4  GHz  and  5  GHz  at  site  A,  B,  D,  and  E  in  this  experiment  are  shown  in 
Figures  14, 15, 16  and  17  respectively: 
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Site  A  Theoretical  900MHzr  2.4GHz  and  5GHz  Spectrum 
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Figure  14  -  Site  A  Theoretical  Spectrum. 


Site  B  Theoretical  2.4GHz  and  5GHz  Spectrum 


Figure  15  -  Site  B  Theoretical  Spectrum. 
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Site  D  Theoretical  900MHzr  2.4GHzand  5GHz  Spectrum 
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Figure  16  -  Site  D  Theoretical  Spectrum. 


.23  80 


0.6  -■ 
0.4  -■ 
0.2  -■ 


5000 


Site  A  Theoretical  2.4GHz  and  5GHz  Spectrum 


T 


_L 


2400 


2420 


2440 


T 


_L 


2460 


5200 


5400  5600 

Frequency  (MHz) 


_L 


2430 


5300 


THEWAPOl 


2500 


THE5BR0 1 


6000 


Figure  17  -  Site  E  Theoretical  Spectrum. 
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In  Figure  14  it  is  apparent  that  there  is  overlap  in  the  2.4  GHz  wireless  connection  to  site 
site  B  and  the  wireless  access  point.  It  was  determined  that  this  overlap  have  minimal  impact 
on  performance  due  to  directional  antennas  used.  The  antennas  were  pointed  in  opposing 
directions  and  were  separated  by  a  concrete  building.  Interference  can  come  from  multiple 
sources  and  have  a  major  impact  on  the  network.  A  device  was  tested  which  drastically 
reduced  throughput  on  the  WLAN  at  one  of  the  sites.  The  root  cause  was  interference  with  the 
2.4  GHz  wireless  access  point.  The  interfering  device  was  a  USB  2.4  GHz  based  wireless  camera. 
This  camera  uses  a  proprietary  frequency  hopping  method  for  the  wireless  capability.  The 
spectrum  impact  when  the  camera  in  enabled  is  shown  in  Figure  18. 


A.  WAP  set  to  channel  5 


B.  Spectrum  with  invasive  camera  enabled 

Figure  18  -  Spectrum  Interference  Caused  by  Frequency  Hopping  Camera. 


Throughput  on  the  wireless  links  is  impacted  severely  when  measured  with  the  JPerf  tool 
shown  in  Figure  19.  After  testing  with  different  channels  on  the  camera  with  the  same  results, 
it  was  determined  that  the  camera  was  not  sufficient  for  adequate  operation  of  this  network 
test  setup  and  was  eliminated.  However,  non-frequency  hopping  devices  can  be  used  in  if 
setup  in  a  manner  to  avoid  interference  with  other  wireless  devices.  The  takeaway  from  this 
finding  is  that  frequency  management  plays  an  important  role  in  wireless  network 
configuration. 
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A.  Throughput  with  invasive  camera  disabled 


B.  Throughput  with  invasive  camera  enabled 

Figure  19  -  Throughput  Impact  from  Frequency  Hopping  Camera. 


3.5  Applications 

The  following  applications  were  used  throughout  experiment.  They  were  selected  due  to  their 
simplicity  and  functionality  representative  of  tactical  applications. 

Mumble 

Mumble  is  an  open-source  Voice  over  Internet  Protocol  (VoIP)  client  available  from 
mumble.sourceforge.net.  It  was  chosen  as  our  VoIP  client  due  to  its  ease  of  setup  and  use. 
Mumble  uses  a  standard  client/server  model,  with  multiple  Mumble  clients  connecting  to  a 
single  server,  known  as  Murmur.  The  Mumble  interface  is  simple,  with  clients  able  to  select  a 
server,  and  once  connected  join  different  channels. 
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Figure  20-  Mumble  Interface. 


Mumble/Murmur  uses  two  channels  of  communication.  First  is  a  control  channel  using  a 
TCP  connection,  used  to  reliably  send  control  data  between  the  client  and  the  server.  The 
second  one  is  a  UDP  connection  used  to  send  voice  data  quickly,  though  unreliably.  In  situations 
where  the  UDP  traffic  is  blocked,  the  voice  traffic  can  be  tunneled  through  the  TCP  connection. 
Both  channels  utilize  strong  encryption  which  is  mandatory  and  cannot  be  disabled.  The  TCP 
control  channel  uses  TLSvl  AES256-SHA,  and  the  voice  channel  uses  OCB-AES128. 

The  connection  between  Mumble  and  Murmur  is  first  established  over  the  TCP  control 
channel  using  a  basic  handshake  and  version  exchange,  establishing  cryptography,  then  the 
server  provides  the  client  with  the  current  channel  states,  user  states,  and  server  sync 
information.  After  this  has  been  established  the  client  attempts  to  make  a  UDP  connection 
through  a  simple  ping.  Once  the  ping  is  responded  to,  all  voice  communications  will  be  sent 
over  this  UDP  channel.  If  UDP  communications  are  interrupted  or  this  ping  is  not  received,  all 
traffic  will  be  tunneled  over  TCP  until  the  UDP  connection  can  be  reestablished. 

Voice  data  is  transmitted  in  variable  length  packets,  which  consist  of  a  header  followed 
by  data  segments.  The  encoded  voice  data  is  contained  in  a  variable  number  of  audio  segments. 
An  optional  positional  audio  segment  may  be  added,  however  this  functionality  was  disable  for 
this  test.  The  UDP  payload  is  limited  to  1020  bytes,  in  order  to  use  a  1024  byte  UDP  buffer  after 
the  4  byte  encryption  header  is  added.  The  UDP  packet  structure  is  broken  down  in  Figure  21. 
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Figure  21  -  UDP  Packet  Structure. 


Mumble  uses  two  different  codecs  for  voice  traffic.  The  first  one  is  Speex 
(www.speex.org) ,  which  is  optimized  for  low  bit  rate  audio.  The  second  is  CELT  (www. celt- 
codec. org),  which  is  used  for  higher  quality  audio.  Newer  versions  of  Mumble  are  replacing 
both  of  these  codecs  with  a  newer  codec  called  Opus  (opus-codec.org/),  but  the  functionality 
remains  the  same.  All  of  these  codecs  are  optimized  for  low  latency,  variable  bitrates,  and 
variable  frame  sizes.  Speex  supports  bitrates  from  2.14-44  kbps,  while  CELT  is  optimized  for  24- 
128  kbps.  Opus  is  designed  to  work  from  6-510  kbps.  In  practice,  these  values  are  varied 
continuously  as  voice  data  is  encoded,  and  the  available  bandwidth  changes.  For  additional 
details  about  the  codecs,  please  consult  their  respective  websites. 

Linphone 

Linphone  was  chosen  as  our  point  to  point  communications  software.  It  offers  voice  and  video 
communications  using  Session  Initiation  Protocol  (SIP).  SIP  is  used  to  establish  and  control 
communications  channels,  but  does  not  require  any  specific  protocol  to  be  used.  It  is  also 
transport  layer  independent,  able  to  operate  over  TCP,  UDP,  or  SCTP  (Stream  Control 
Transmission  Protocol).  It  is  also  capable  of  using  TLS  for  security.  A  chart  of  SIP  requests  is 
shown  in  Table  4. 
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Table  4  -  SIP  Messages. 


Request 

Description 

Defined  in 

INVITE 

Indicates  a  client  is  being  invited  to  participate  in  a  call  session. 

RFC  3261 

ACK 

Confirms  that  the  client  has  received  a  final  response  to  an  INVITE 
request. 

RFC  3261 

BYE 

Terminates  a  call  and  can  be  sent  by  either  the  caller  or  the  callee. 

RFC  3261 

CANCEL 

Cancels  any  pending  request. 

RFC  3261 

OPTIONS 

Queries  the  capabilities  of  servers. 

RFC  3261 

REGISTER 

Registers  the  address  listed  in  the  To  header  field  with  a  SIP  server. 

RFC  3261 

PRACK 

Provisional  acknowledgement. 

RFC  3262 

SUBSCRIBE 

Subscribes  for  an  Event  of  Notification  from  the  Notifier. 

RFC  3265 

NOTIFY 

Notify  the  subscriber  of  a  new  Event. 

RFC  3265 

PUBLISH 

Publishes  an  event  to  the  Server. 

RFC  3903 

INFO 

Sends  mid-session  information  that  does  not  modify  the  session  state. 

RFC  6086 

REFER 

Asks  recipient  to  issue  SIP  request  (call  transfer.) 

RFC  3515 

MESSAGE 

Transports  instant  messages  using  SIP. 

RFC3428 

UPDATE 

Modifies  the  state  of  a  session  without  changing  the  state  of  the  dialog. 

RFC3311 

Linphone  is  capable  of  using  a  variety  of  codecs  for  both  voice  and  video  channels. 
Supported  voice  codecs  include  Speex  (as  was  used  with  Mumble),  G.711  (both  p-law  and  A- 
law),  GSM  (as  used  in  cellular  telephony),  and  iLBC  through  a  plugin,  which  was  not  used  in  this 
test.  Supported  video  codecs  are  VP8,  H263,  MPEG-4,  Theora,  and  H.264,  with  varying 
resolutions  dependent  on  network  bandwidth  and  CPU  power. 

For  the  purposes  of  this  experiment,  Linphone  was  only  used  as  a  demonstration  of 
point  to  point  video  communications  using  the  laptops'  built  in  cameras.  The  default  settings  of 
Speex  and  VP8  codecs  where  kept,  with  adaptive  rate  control  enabled.  One  limitation  of 
Linphone  is  the  inability  to  conference  multiple  video  links.  However,  voice  conferencing  is 
possible. 

VLC 

VLC  Media  Player  was  used  as  a  client  to  receive  the  various  video  streams  from  the  different 
cameras  set  up  during  the  experiment.  VLC  was  chosen  because  it  supports  a  broad  set  of 
protocols  and  codecs. 

Each  camera  operated  with  a  different  codec  and  streaming  protocol,  and  a  separate 
instance  of  VLC  was  opened  for  each  stream.  The  FOSCAM  FI8910W  pan  and  tilt  cameras  used 
the  MJPEG  video  codec  over  a  standard  HTTP  link.  The  D-Link  DCS-942L  cameras  used  the 
MPEG-4  video  codec,  streamed  using  Real-Time  Streaming  Protocol  (RTSP).  RTSP  is  designed 
specifically  for  multimedia  playback,  with  control  sequences  sent  over  an  established  TCP 
connection.  In  conjunction  with  RTSP  is  RTP  (Real-Time  Transport  Protocol),  which  carries  the 
actual  video  traffic.  The  RTP  packet  header  format  is  shown  in  Figure  22. 


Approved  for  Public  Release;  Distribution  Unlimited. 
21 


bit  offset 

0-1 

2 

3 

4-7 

8 

9-15 

16-31 

0 

Version 

P 

X 

ee 

M 

PT 

Sequence  Number 

32 

Timestamp 

64 

SSRC  identifier 

36 

CSRC  identifiers 

96+32*CC 

Profile-specific  extension  header  ID  Extension  header  length 

1 28+32 *CC 

Extension  header 

Figure  22  -  RTP  Packet  Header. 


The  extension  is  where  the  video  data  is  contained.  The  RTP  payload  is  defined  by  the 
Payload  Type  (PT)  segment,  which  are  predefined  in  RTP  profiles.  For  additional  information 
about  RTP,  consult  RFC  3550  and  3551. 

An  additional  functionality  of  VLC  that  was  tested  in  the  lab  is  its  ability  to  accept  video 
input,  transcode  (if  desired),  and  stream  it  through  a  selected  protocol.  Available  protocols 
include  standard  HTTP  traffic,  RTSP  and  RTP  streams,  and  UDP  streams  (which  can  be  broadcast 
on  a  multicast  address).  This  can  be  used  to  stream  analog  video  through  a  computer,  out  into 
the  network.  The  ASTAK  CM842T  cameras  required  this  functionality  in  order  to  be  streamed 
over  the  network,  as  they  only  provided  analog  video  output. 

Iperf/Jperf 

Iperf  is  an  open  source  command  line  network  testing  tool  that  is  able  to  create  TCP  and  UDP 
data  streams  and  measure  their  throughput.  It  operates  on  a  client-server  model  with  one 
instance  of  iPerf  sending  data  to  another,  though  it  is  also  able  to  operate  in  bidirectional 
modes.  When  operating  in  TCP  mode,  Iperf  measures  the  maximum  throughput  of  the  link  in 
real-time,  with  available  bandwidth  increasing  or  decreasing  with  the  presence  of  other 
network  traffic.  In  UDP  mode,  the  user  sets  the  bandwidth  Iperf  will  attempt  to  use,  and  then 
Iperf  will  measure  the  actual  throughput.  This  method  can  be  used  to  stress  test  the  network  by 
generating  more  traffic  than  the  network  can  support. 
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Figure  23  -  Iperf  ScreenShot. 


Jperf  is  a  graphical  frontend  for  Iperf,  providing  the  user  with  an  easy  to  use  interface  as 
well  as  charts  of  current  bandwidth  results.  This  allows  for  easy  visualization  of  network  traffic, 
and  the  effects  of  various  disruptions  to  throughput,  as  seen  in  Figure  24.  It  is  possible  to  run 
multiple  instances  of  Iperf/Jperf  on  a  single  link,  allowing  measurement  of  bandwidth  while 
traffic  is  generated. 


Figure  24  -  JPerf  Screenshot. 
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4.0  Results  and  Discussion 


To  capture  the  performance  of  the  JALN  surrogate  and  to  expose  the  JALN  Gaps  an  experiment 
under  the  pretenses  to  support  a  disaster  response  operation  was  developed.  The  experiment 
featured  six  scenarios  that  were  performed  on  26  October  2012. 

Four  preliminary  tasks  were  conducted  prior  to  the  start  of  these  scenarios  to  ensure 
smooth  test  execution.  The  first  Pre-Op  was  to  provide  communication  between  local  site 
members  via  900  MHz  hand-held  radios.  The  second  was  to  ensure  link  connectivity  between 
all  network  nodes.  This  was  accomplished  using  a  32-bit  Internet  Control  Message  Protocol 
(ICMP)  packet  that  was  sent  to  every  node  from  each  workstation.  The  third  was  to  run  packet 
monitoring  software  to  enable  real  time  collection  at  each  host.  This  was  accomplished  using 
Wireshark  network  protocol  analyzer.  The  fourth  was  to  run  bandwidth  monitoring  software  to 
allow  remote  host  connections  for  bandwidth  measurements.  This  was  accomplished  by 
opening  a  server  on  each  node  using  JPERF  GUI  tool  for  IPerf. 

Once  these  Pre-Ops  were  accomplished,  the  following  Scenarios  were  conducted 
respectfully. 


4.1  Scenario  1:  Emergency  Team  Check-In 

The  first  scenario's  objective  was  to  establish  VoIP  communications  with  all  disaster  response 
team  members  across  all  four  sites.  As  previously  mentioned,  a  server-client  based  application 
called  Murmur  (server)  and  Mumble  (client)  was  used.  Murmur  and  Mumble  were  installed 
and  operated  on  THALTP01,  while  all  other  manned  workstation  ran  the  client  application 
Mumble  only.  Through  the  Murmur  server  application  a  VoIP  network  called  "Main  Ops  Net" 
was  created  and  all  clients  were  joined  to  this  network.  A  roll  call  was  then  performed  and  the 
clarity  of  the  voice  transmissions  was  measured  qualitatively.  All  members  were  able  to 
effectively  transmit  and  receive  voice  communication  without  degradation.  Quantitative  data 
was  collected  as  well.  Table  5  shows  the  typical  traffic  generated  from  Murmur  and  Mumble. 


Table  5  -  Murmur  and  Mumble  Packet  Capture. 


Source 

Destination 

Protocol 

Length 

Info 

172.10.0.10 

172.40.0.10 

TCP 

107 

64738  >50731  [PSH,  ACK]  Seq=l  Ack=70  Win=253  Len=53 

<- 

Packet  sent  from  Murmur  server  ensure  up  state  of  Mumble  client 

172.40.0.10 

172.10.0.10 

TCP 

60 

50731  >  64738  [ACK]  Seq=70  Ack=54  Win=16199  Len=0 

<- 

Acknowledgement  sent  back  from  Mumble  client 

172.40.0.10 

172.10.0.10 

UDP 

60 

Source  port:  63439  Destination  port:  64738 

<- 

Voice  Tx  from  172.40.0.10  to  172.10.0.10 

172.10.0.10 

172.40.0.10 

UDP 

151 

Source  port:  64738  Destination  port:  63439 

<  [Voice  Tx  from  172.10.0.10  to  172.40.0.10 

172.10.0.10 

172.40.0.10 

UDP 

151 

Source  port:  64738  Destination  port:  63439 

<- 

-  Voice  Tx  from  172.10.0.10  to  172.40.0.10 

172.40.0.10 

172.10.0.10 

UDP 

60 

Source  port:  63439  Destination  port:  64738 

-  Voice  Tx  from  172.40.0.10  to  172.10.0.10 

Approved  for  Public  Release;  Distribution  Unlimited. 
24 


4.2  Scenario  2:  Launch  Local  Video  Feeds 


The  second  scenario’s  objective  was  for  each  manned  workstation  to  gain  visual  situational 
awareness  of  their  local  responsible  disaster  area.  This  involved  launching  video  streams  from 
IP  video  cameras  only  running  within  their  local  subnet.  A  list  of  each  sites’  video  sources  can 

be  seen  in  Table  6. 


Table  6  -  Site  Video  Sources. 


Site 

Device 

Manufacturer 

PN 

Resoultion 

FPS 

Codec 

A 

THACAM01 

FOSCAM 

FI8910W 

640  x  480 

30 

MJPEG 

A 

THACAM02 

DLink 

DCS-942L 

640  x  480 

30 

MPEG-4 

B 

IHBCAM01 

FOSCAM 

FI8910W 

640  x  480 

30 

MJPEG 

B 

IHBCAM02 

DLink 

DCS-942L 

640  x  480 

30 

MPEG-4 

D 

IHDCAM01 

FOSCAM 

FI8910W 

640  x  480 

30 

MJPEG 

D 

IHDCAM02 

DLink 

DCS-942L 

640  x  480 

30 

MPEG-4 

D 

IHDCAM03 

Astak 

CM842T 

D 

IHDCAM04 

Looxcie 

LX2 

640  x  480 

30 

MPEG-4 

E 

THECAM01 

FOSCAM 

FI8910W 

640  x  480 

30 

MJPEG 

E 

THE  CAM 02 

DLink 

DCS-942L 

640  x  480 

30 

MPEG-4 

E 

THE  CAM  03 

FOSCAM 

FI8910W 

640  x  480 

30 

MJPEG 

E 

THE  CAM 04 

Looxcie 

LX2 

640  x  480 

30 

MPEG-4 

E 

THE  CAM  05 

Astak 

CM842T 

All  IP  video  cameras  broadcasted  their  feeds  over  TCP  Port  80.  A  custom  program  using 
VideoLAN  (VLC)  was  written  to  simply  launching  all  of  IP  video  streams  for  each  subnet.  During 
this  scenario  each  manned  workstation  was  able  to  successfully  launch  all  of  their  local  video 
feeds.  Qualitatively,  all  video  streams  delivered  a  crisp,  smooth  picture  with  very  little  latency 
and  providing  team  members  effective  situational  awareness  of  their  responsible  site.  The 
available  bandwidth  across  each  site's  local  subnet  was  reduced  due  to  the  number  of  high 
resolution  video  streams  traversing  the  network.  For  instance,  Figure  25  shows  the  bandwidth 
between  a  wired  and  wireless  workstation  at  site  E  before  and  after  video  streams  are 
launched.  As  seen  in  the  figure,  the  bandwidth  is  significantly  reduced  when  the  first 
workstation  launches  the  five  streams  and  further  reduced  when  another  workstation 
launches. 
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Site  E  Wireless  Link  BW  vs  Time 


Wireless  Laptop  Wired  Laptop 

(THELTP02)  (THELTP01) 

Launches  Launches 


TrHTrHTHTrH(Nr^cNnr)rorO'T^-^-^-ii^un)L!!n5kD^^rNrNr^pNtxjootX)mmcRo 


Time  (sec) 


Figure  25  -  Site  E  jPerf  results  between  wired  and  wireless  workstations. 


4.3  Scenario  3:  Launch  Remote  Video  Feeds 

The  third  scenario's  objective  was  to  enhance  situational  awareness  across  all  sites. 

Specifically,  this  included  launching  video  streams  from  all  sites,  on  each  manned  workstation. 
The  same  custom  program  was  used  to  launch  these  video  streams.  During  this  event,  network 
performance  was  significantly  degraded.  Workstations  were  still  able  to  launch  local  video 
streams;  however,  when  pulling  remote  video  streams  they  were  either  extremely  slow  to 
launch  or  failed  to  launch  entirely.  Streams  that  would  launch  had  high  latency  and  provided 
choppy  video.  Figure  26  shows  the  bandwidth  of  the  site  E's  wireless  link  during  this  scenario. 
The  figure  also  identifies  bandwidth  after  each  node  pulls  the  video  streams  from  site  E. 

In  addition  to  these  issues,  other  network  resources  were  impacted,  such  as  VoIP 
communication  and  desktop  sharing.  Due  to  the  limited  bandwidth  available  at  Site  A,  the 
Murmur  server  was  unable  to  keep  alive  VoIP  sessions.  Malformed  Murmur  packets  and 
mumble  checksum  errors  can  be  seen  in  Table  7.  The  packets  also  show  that  data  was  only  lost 
from  Site  E's  workstation  to  Site  A's  workstation. 
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Site  E  Wireless  link  BW  vs  Time 


E02  Launches 


Time  (s) 


Figure  26  -  Site  E  jPerf  Link  BW  measurements  made  during  remote  video  stream  launches. 


Table  7  -  Murmur  and  Mumble  Malformed  Packets  and  Checksum  Errors. 


4.4  Scenario  4:  File  Transfer 

The  fourth  scenario's  objective  was  to  send  file  data  (180  MB)  from  each  manned  workstation 
at  sites  B,  D  and  E  to  A.  This  was  to  determine  the  rate  at  which  files  could  be  transferred  and 
to  identify  any  associated  impacts  to  other  network  resources.  This  event  was  effectively 
completed.  In  all  cases,  data  was  quickly  transferred  from  each  manned  workstation  to  site  A. 
Table  8  shows  the  data  rate  and  time  for  each  upload  to  Site  A. 
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Table  8  -  File  Transfer  Rates. 


Device 

Start  Time 

End  Time 

Rate  (MBps) 

THALTP02 

11:04 

11:11 

1.24 

THALTP03 

11:03 

11:11 

1.2 

IHBLTP01 

11:03 

11:05 

4.45 

IHBLTP02 

11:03 

11:06 

2.2 

IHDLTP01 

11:05 

11:09 

4.5 

IHDLTP02 

11:04 

11:06 

4 

THELTP01 

11:07 

11:10 

8.6 

THELTP02 

11:06 

11:09 

2.5 

4.5  Scenario  5:  Link  Overload 

The  fifth  scenario's  objective  was  to  demonstrate  a  link  failover  for  an  overloaded  primary  link. 
Link  overload  occurs  when  there  is  enough  traffic  on  a  link  such  that  the  ping  response  times 
out  on  the  corresponding  link.  Link  overload  was  achieved  by  utilizing  the  MikroTik  router's 
traffic  generator  to  flood  the  primary  link  to  site  D.  Performance  monitoring  was  achieved  by 
using  jPerf.  The  expected  result  is  to  see  throughput  degradation  once  the  traffic  generator  is 
enabled,  throughput  drop  to  nearly  zero,  switch  to  secondary  900  MHz  link  and  throughput 
adjust  accordingly. 

Once  the  through  put  became  noticeably  higher  (and  the  traffic  generator  still  flooding 
the  primary  link  with  traffic),  a  path  ping  was  used  to  verify  the  link  failover.  Once  the  pathping 
verified  failover  the  traffic  generator  was  disabled  on  the  MikroTik  and  the  link  was  restored  to 
normal  operation  on  the  primary  5  GHz  link.  The  results  of  this  process  are  documented  in 
Figure  27. 
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ScenanoS:  Link  Overload 


A:  5GHz  Primary  Link. 

B:  Traffic  Generator  enabled,  link  throughput  degration. 

C:  Failover  to  900MHz  secondary  link. 

D:  Traffic  Generator  disabled,  link  returns  to  primary  5GHz  Link. 


Figure  27  -  Site  A  Scenario  5  -  Link  Overload. 


4.6  Scenario  6:  Link  Loss 

The  sixth  scenario's  objective  was  to  demonstrate  link  and  routing  failure/recovery.  In  a 
tactical  scenario  this  would  represent  an  airborne  or  ground  node  exceeding  the  backbone 
distance  requirement  or  becoming  completely  compromised.  The  scenario  in  this  setup  will 
verify  four  link  failovers  and  recoveries.  Each  link  was  assigned  a  metric  (in  the  static  routing 
table),  therefore  if  a  link  goes  down  the  traffic  will  be  routed  through  the  link  with  the  next 
highest  metric  that  is  available.  Link  metrics  can  be  seen  in  Table  9. 
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Table  9  -  Link  Metrics. 


Link 

Destination 

Gateway 

Priority 

Metric 

5  GHz  A-D 

172.30.0.0/16 

192.168.30.4 

Primary 

2 

900  MHz  A-D 

172.30.0.0/16 

192.168.40.4 

Secondary 

4 

CDL  A-D 

172.30.0.0/16 

192.168.70.4 

Tertiary 

6 

5  GHz  A-B-D 

172.30.0.0/16 

192.168.20.4 

Quaternary 

8 

2.4  GHz  A-B-D 

172.30.0.0/16 

192.168.10.4 

Quinary 

10 

The  link  failover  occurs  in  the  following  order:  Site  A  -  Site  D  5  GHz  Link,  Site  A  -  Site  D 
900  MHz  link,  Site  A  -  Site  D  CDL  link,  Site  A -Site  B  5  GHz  link  -  Site  D  5  GHz  link  and  Site  A - 
Site  B  2.4  GHz  link  -  Site  D  5  GHz  Link.  The  failure  is  accomplished  by  simply  disconnecting  each 
link  from  Site  A's  router  -  effectively  creating  an  instantaneous  downed  link.  The  flow  diagram 
shown  in  Figure  28  represents  the  process  described  above. 


Connect 

5GHz  Primary  ^ 


Disconnect 
5GHz  Primary 


Connect 

900MHz  Secondary 


Disconnect 
90QMHz  Secondary 


connect  \ 
CDL  Tertiary 


Disconnect 
i/  CDL  Tertiary 


5GHz  Quaternary 


Disconnect 
5GH2  Quaternary 


Figure  28  -  Scenario  6  Link  Loss  State  Diagram. 


The  throughput  was  monitored  with  JPerf  during  this  scenario.  From  the  data  collected 
it  is  evident  when  each  link  fails  over.  The  data  is  shown  in  A:  5  GHz  Primary  a-d. 
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B:  900  MHz  Secondary  A-D. 
C:  CDL  Tertiary  A-D. 

D:  5  GHz  Quaternary  A-B-D. 
E:  2.4  GHz  Quinary  A-B-D. 
F:  5  GHz  Quaternary  A-B-D. 
G:  CDL  Tertiary  A-D. 

H:  900  MHz  Secondary  A-D. 
I:  5  GHz  Primary  A-D. 


Figure  29  below  (Corresponding  states  indicated  by  letters  A-l  correspond  to  the  letters 
in  Figure  29. 


Scenario  6:  Link  Loss 
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A:  5  GHz  Primary  A-D. 

B:  900  MHz  Secondary  A-D. 

C:  CDL  Tertiary  A-D. 

D:  5  GHz  Quaternary  A-B-D. 

E:  2.4  GHz  Quinary  A-B-D. 

F:  5  GHz  Quaternary  A-B-D. 

G:  CDL  Tertiary  A-D. 

H:  900  MHz  Secondary  A-D. 

I:  5  GHz  Primary  A-D. 

Figure  29  -  Scenario  6  -  Link  Loss. 
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It  is  important  to  note  that  having  dedicated  links  and  only  failover  backups  will 
eventually  result  in  link  overload  if  the  link  is  flooded  with  data,  similar  to  scenario  5.  In  this 
situation  the  primary  link  will  saturate  and  fail  over  to  the  secondary  link  and  all  traffic  will  be 
routed  on  that  path.  If  the  secondary  link  cannot  handle  the  amount  of  traffic  on  the  link  it  will 
also  fail.  This  will  happen  inevitably  so  long  as  there  is  too  much  data  for  the  links  to  handle. 

To  mediate  this  risk  load  balancing  can  be  performed.  Load  balancing  distributes  the  workload 
across  multiple  available  links  to  maximize  throughput.  In  this  experiment  load  balancing  will 
improve  throughput  across  bottlenecked  wireless  links. 
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5.0  CONCLUSIONS 


Field  measurements  carried  at  AFRL's  Newport  Test  Facility  demonstrated  that  COTS  wireless 
networking  technology  can  be  used  for  investigation  of  JALN  related  architecture  and 
operations  issues.  The  network  topology  used  in  the  experiment  the  communication  paths  that 
were  installed  between  AFRL's  Rome  and  Stockbridge  Test  Sites.  Follow-on  experiments  will 
be  required  to  verify  that  the  networking  approach  is  sufficiently  scalable  so  as  to  allow  for  the 
investigation  of  larger,  more  complex,  network  configurations  like  those  expected  to  be 
realized  in  future  ALNs. 


Approved  for  Public  Release;  Distribution  Unlimited. 
33 


6.0  RECOMMENDATIONS 


Going  forward,  work  should  first  focus  on  better  understanding  the  current  JALN  capabilities 
and  specific  weaknesses.  Objectives  and  goals  should  be  well  defined  to  ensure  continued  work 
meets  the  needs  of  the  JALN  effort.  In  particular,  the  types  of  tactical  applications  and 
scenarios  should  be  defined  and  described  to  ensure  proper  surrogate  design.  To  gain  insight, 
direct  interaction  should  be  made  with  JALN  working  groups  and  the  Joint  Tactical  Edge 
Network  (JTEN).  Industry  research  should  also  be  conducted  to  lessen  the  risk  for  duplication 
of  effort  and  to  ensure  that  a  plausible  solution  is  neither  already  in  work  or  exists.  This  should 
include  LIT  and  Defense  Technical  Information  Center  (DTIC)  report  searches. 

6.1  Simulations 

Simulation  of  network  functionality  should  be  integrated  into  the  JALN  surrogate  design.  This 
would  help  characterize  network  performance  for  a  scaled  number  of  nodes.  This  type  of 
simulation  could  be  performed  prior  or  after  field  experimentation  as  either  a  baseline  or  to 
confirm  measured  data.  Simulation  would  also  help  identify  parts  of  the  network  that  may  be 
or  become  bottlenecks  under  network  loading.  OPNET  enables  planning  and  design  of 
networks  with  industry  standard  protocols  and  built-in  device  models. 

6.2  Address  Structure 

The  address  structure  should  also  be  reinvestigated.  IPv6  offers  addresses  to  automatically 
configure  through  Stateless  Autoconfiguration.  Stateless  Autoconfiguration  allows  for 
automated  IP  address  configuration  without  the  use  of  dynamic  host  configuration  protocol 
(DHCP).  Autoconfiguration  of  an  individual  node  derives  tentative  link-local  addresses  with  a 
prefix  of  FE80::/64  and  initiates  Duplicate  Address  Detection  (DAD)  to  verify  uniqueness  of  the 
local  link.  Autoconfiguration  also  could  prove  to  be  very  useful  in  the  JALN  due  to  its  ease  of 
address  configuration.  This  will  also  assist  with  network  entry/exit.  With  Autoconfiguration  the 
new  nodes  will  simply  move  into  range  to  join  the  network. 

6.3  Routing 

Static  routing,  like  that  used  in  this  experiment,  is  the  simplest  form  of  routing  -  however  it  is 
entirely  manual.  Static  routing  is  beneficial  when  there  are  a  relatively  low  number  of  devices  in 
the  network  and  the  routes  are  not  likely  to  change.  In  a  realistic  the  JALN  scenario,  static 
routing  is  a  constraining  factor.  That  is  to  say,  if  a  node  is  added  to  the  network  it  will  need  to 
be  manually  configured  and  the  operator  must  know  the  subnet  that  the  device  will  be  used  on. 
Dynamic  routing  protocols  reduce  the  amount  of  configuration  by  'learning'  the  network  which 
they  are  connected  to.  Dynamic  routing  protocols  allow  routers  to  dynamically  learn  network 
destinations,  the  route  to  them  and  how  to  advertise  them  to  other  routers.  Directly  connected 
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routers  also  have  the  ability  to  learn  routes  from  their  next  hop  running  a  different  routing 
protocol.  A  Router  can  then  sort  through  their  list  of  routes  and  select  one  or  more  best  routes 
for  each  network  destination  the  router  knows  or  has  learned.  Utilizing  dynamic  routing  in  this 
scenario  will  benefit  the  wireless  versatility  of  the  JALN  network. 
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8.0  LIST  OF  SYMBOLS,  ABBREVIATIONS,  AND  ACRONYMS 


ALN 

Aerial  Layered  Network 

AP 

Access  Point 

CDL 

Common  Data  Link 

COTS 

Commercial-Of-The-Shelf 

DAD 

Duplicate  Address  Detection 

DHCP 

Dynamic  Host  Configuration  Protocol 

DTIC 

Defense  Technical  Information  Center 

GHz 

Giga  Hertz 

GSM 

Global  System  for  Mobile 

GUI 

Graphical  User  Interface 

HTTP 

Hyper  Text  Transfer  Protocol 

ICMP 

Internet  Message  Control  Protocol 

IPv6 

Internet  Protocol  version  6 

JALN 

Joint  Aerial  Layered  Network 

JTEN 

Joint  Tactical  Edge  Network 

Mbps 

Mega  bits-per-second 

MHz 

Mega  Hertz 

PT 

Payload  Type 

RTP 

Real-time  Transport  Protocol 

RTSP 

Real  Time  Streaming  Protocol 

SCTP 

Stream  Control  Transmission  Protocol 

SIP 

Session  Initiation  Protocol 

TCP/IP 

Transmission  Control  Protocol/Internet  Protocol 

TLS 

Transport  Layer  Security 

OV 

Operational  View 

UDP 

User  Datagram  Protocol 

VoIP 

Voice  over  Internet  Protocol 

WiFi 

Wireless  Fidelity 

WLAN 

Wireless  Local  Area  Network 
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